app/AppContainer.tsx (2)

51-53: Consider handling the font-loading wait with SplashScreen to prevent a blank-screen flash.

With the corrected guard (|| !root), the component returns null during both font loading and root initialization. This can produce a visible blank screen. The expo-splash-screen library provides a SplashScreen component that you can use to prevent rendering the app until the font is loaded and ready. Pairing SplashScreen.preventAutoHideAsync() at the module level and SplashScreen.hideAsync() once loaded || fontError would give a smoother experience on slow devices where this font load is most likely to be perceptible.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/AppContainer.tsx` around lines 51 - 53, Change the current guard that
returns null during font/root init to use the Expo SplashScreen flow: call
SplashScreen.preventAutoHideAsync() at module load, keep rendering until the app
is ready, and when either loaded || fontError || root is truthy call
SplashScreen.hideAsync() before returning the app UI; update references in
AppContainer.tsx around the loaded, fontError and root checks to stop returning
null directly and instead hide the splash once ready. Ensure you import
expo-splash-screen and only call hideAsync once (and handle errors) so the
splash prevents the blank-screen flash during font loading.

---

47-49: Font loading should be hoisted to the app entry point, not placed inside the navigation container component.

Expo recommends mapping font files using the useFonts hook in a top-level component such as the root layout file. Placing it here means font loading won't begin until this connected component mounts (after Redux store setup and initial render), adding unnecessary latency. A font loading failure or slow load will block the entire navigation stack.

For Android/iOS specifically, there are two ways to add fonts: using the expo-font config plugin (recommended for Android and iOS) or loading them at runtime. On Android and iOS, the plugin allows you to embed font files at build time, which is more efficient than useFonts or loadAsync. Since the issue is specifically about older Android, the config plugin would be the more robust long-term fix.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/AppContainer.tsx` around lines 47 - 49, The useFonts call inside
AppContainer should be removed and font loading hoisted to the app entry point
(e.g., App.tsx / root layout) so fonts load before the navigation stack mounts;
locate and delete the useFonts invocation in AppContainer and instead load the
same './static/fonts/custom.ttf' at app startup (using useFonts in the root
component or, for Android/iOS, configure the expo-font config plugin to embed
the font at build time), and update AppContainer to assume fonts are already
available.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

app/AppContainer.tsx (1)

47-51: fontError is silently swallowed — consider logging it for diagnostics.

When fontError is non-null the app falls back to rendering without the custom font, which is the right behaviour, but nothing records that the failure happened. On the exact devices this PR targets (older Android), a future regression would be completely invisible.

🔍 Suggested observability improvement

 	const [loaded, fontError] = useFonts({
 		custom: require('./static/fonts/custom.ttf')
 	});
+
+	if (fontError) {
+		console.warn('[AppContainer] Custom font failed to load:', fontError);
+		// or log to your error-reporting service, e.g. logEvent(...)
+	}
 
 	if ((!loaded && !fontError) || !root) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/AppContainer.tsx` around lines 47 - 51, When useFonts returns a non-null
fontError in AppContainer.tsx, log the error for diagnostics without changing
the fallback behavior; add a single log (e.g., console.error or your app logger)
that runs when fontError is truthy (reference useFonts and the fontError
variable) and include a clear message like "Failed to load custom font" plus the
error object so older Android font failures are recorded. Place the log right
before the existing early-return/render fallback that checks "if ((!loaded &&
!fontError) || !root)" so behavior stays identical but the failure is
observable.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

app/AppContainer.tsx (1)

51-53: Move font error logging into a useEffect to avoid side effects during render.

log(fontError) runs on every re-render when the error is set (e.g., when root or isMasterDetail changes via Redux). Render should be pure — side effects belong in useEffect. This also prevents duplicate logs in React 19 Strict Mode's double-render.

♻️ Proposed fix

+	useEffect(() => {
+		if (fontError) {
+			log(fontError);
+		}
+	}, [fontError]);
+
-	if (fontError) {
-		log(fontError);
-	}
-
 	if ((!loaded && !fontError) || !root) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/AppContainer.tsx` around lines 51 - 53, The font error logging is causing
a render-side effect — move the log(fontError) call out of the render body of
the AppContainer component into a useEffect that runs only when fontError
changes; add import { useEffect } from React if missing, create useEffect(() =>
{ if (fontError) log(fontError); }, [fontError]) so logging happens only once
per error and avoids duplicate logs in Strict Mode and other re-renders.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

app/AppContainer.tsx (1)

51-55: Consider user-visible fallback when font loading fails.

When fontError is truthy, the app proceeds to render but the custom font won't be loaded, meaning icons will still be missing. The error is logged, but users on affected devices will see the broken icon state.

Consider whether to:

1. Display a fallback UI or error message to users
2. Retry font loading
3. Accept this as acceptable degradation (log-only is sufficient)

If option 3 is intentional, this is fine as-is.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/AppContainer.tsx` around lines 51 - 55, The useEffect watching fontError
currently only calls log(fontError) and leaves users seeing broken icons; update
the handling for fontError (in the useEffect and related render logic in
AppContainer and any font-loading functions) to provide a user-visible fallback:
either set a new state like useFallbackIcons (toggled when fontError is truthy)
and render system-font/icon fallbacks or a small non-blocking banner/error
message, or implement a retry attempt (call your font load function with
exponential backoff from the useEffect) and fall back to system fonts if retries
fail; pick one approach, wire the state into the render path so icons/fonts
degrade gracefully instead of silently logging.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes